Skip to content

NAT64/Teredo Embedding Strategies + Public/Private Blocks#105

Closed
zanbaldwin wants to merge 6 commits into
6.xfrom
z/nat64
Closed

NAT64/Teredo Embedding Strategies + Public/Private Blocks#105
zanbaldwin wants to merge 6 commits into
6.xfrom
z/nat64

Conversation

@zanbaldwin

Copy link
Copy Markdown
Member

No description provided.

Add embedding strategy for NAT64 "Well-Known Prefix" `64:ff9b::/96` defined by RFC 6052 § 2.1 (with test coverage and data providers).
Include docblocks for the other strategies that explain their defining RFC.
Add composite embedding that delegates checks/extraction to multiple underlying strategies (always uses first-defined strategy for packing).
Named constructor `all()` covers all unambiguous, non-deprecated embedding, with Mapped as the canonical packer.
Includes test coverage and data provider.
isUnicastGlobal() only inspected 16-byte IPv6 form, meaning a non-global IPv4-embedded address (loopback, private, etc) was reported as global. Error also cascaded down to isPublicUse().
Bug could potentially allow a non-global address to slip past an SSRF/ACL guard/deny-list.
Embedded addresses are now canonicalised before classifying.

Note: IPv6 now checks ALL valid IPv4-embeddings (previously only Multi checked, and only checked its singularly-assigned embedding).
Add extraction-only embedding strategy for the Teredo tunnelling prefix `2001::/32` defined by RFC 4380 § 4 (with test coverage and data providers).
The IANA special-purpose registry lists the NAT64 local-use block `64:ff9b:1::/48` (defined by RFC 8215; different to the NAT64 well-known prefix) as not globally reachable, but `isUnicastGlobal()` and `isPublicUse()` report addresses within it as global. Fix: explicitly exlcude them.
Operator-defined, cannot be decoded by an embedding strategy, must be excluded as a whole instead of being canonicalised.
@zanbaldwin zanbaldwin self-assigned this Jun 3, 2026
Comment thread src/Strategy/Nat64.php
* Globally reachable, but not reserved by protocol. RFC 6052 § 3.1 states that
* non-global IPv4 addresses must NOT be embedded as NAT64.
*/
class Nat64 implements EmbeddingStrategyInterface

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since NAT64 supports prefixes other than 64:ff9b::/96, would it be possible to add the option to specify a different checksum-neutral prefix for NAT64?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have been reading RFC specifications for nearly 2 days, so my brain needs a rest right now, but I have seen this and I will reply some time in the next couple of days 👍

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about adding named constructors to NAT64:

  • Nat64::wellKnown() (default, part of Composite::all()), and
  • Nat64::networkSpecific(IPv6 $prefix, int $cidr) where $cidr must be one of 32, 40, 48, 56, 64, or 96.
  • Also something about NAT64 local-use, because that entire block is defined as not globally reachable, but not sure where that logic is going to go (just made a private helper method in the other pull requests).

Will probably cancel this pull request, and do just the NAT64 stuff on its own in a new pull request on Monday. Will tag you in it for review (unless you leave any comments here before then).

Thanks for the suggestion!

@zanbaldwin zanbaldwin marked this pull request as draft June 6, 2026 17:15
@zanbaldwin zanbaldwin added feature New feature (minor version bump) bug Library execution is contradictory to expected/documented behaviour labels Jun 7, 2026
@zanbaldwin zanbaldwin closed this Jun 8, 2026
@zanbaldwin zanbaldwin deleted the z/nat64 branch June 8, 2026 21:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Library execution is contradictory to expected/documented behaviour feature New feature (minor version bump)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants